Skip to content

Conversation

@rli
Copy link
Contributor

@rli rli commented Apr 15, 2025

If response code is not 200 then we never break out of the retry loop

License

I confirm that my contribution is made under the terms of the Apache 2.0 license.

@rli rli requested a review from a team as a code owner April 15, 2025 22:05
@github-actions
Copy link

github-actions bot commented Apr 15, 2025

Qodana Community for JVM

It seems all right 👌

No new problems were found according to the checks applied

💡 Qodana analysis was run in the pull request mode: only the changed files were checked
☁️ View the detailed Qodana report

Contact Qodana team

Contact us at [email protected]

@rli rli enabled auto-merge (squash) April 15, 2025 22:51
@rli rli merged commit 3357e88 into main Apr 15, 2025
16 of 18 checks passed
@rli rli deleted the rli/init-loop branch April 15, 2025 23:58
rli pushed a commit that referenced this pull request Apr 17, 2025
Orphaned http request that should be rejected somehow sneaked into the http request event loop while the FAISS index is not ready, causing the workspace LSP process to terminate, which causes the JetBrains IDE to re-initialize the workspace LSP process, which further triggers an infinite loop of log storm that caused slowness (the log loop issue is fixed in #5581). 

Here are the sequence of events that happened:

1. JB starts workspace LSP, the LSP then works on tree sitter parsing to generate repomap.
2. When #1 is in progress, client (user) uses @workspace feature sends a request for vector index query. #1 is usually fast but for 1.4GB repo like https://github.com/elastic/elasticsearch (1.4GB), it takes 6 min. 
3. Node js event loop busy, client request #2 is timed out. However, requests is cached at server and it becomes an Orphaned http request.
4. The moment when tree sitter parsing is done, node js event loop SOMEHOW immediately handles the Orphaned request in step 2 at a certain possibility!
5. The vector index is not undefined, it was partially initialized, but it had no chunk inside, query when 0 chunks caused Faiss to crash, which terminated the LSP process.
6. JB saw java.net.ConnectException: Connection refused, it then forces LSP to restart, which restarts the indexing, causing performance issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants